Hardcoded files
This page describes fixed files retrieved and loaded by the game, used internally for mechanics and data sources that end up as the basic data tables and resources that are consumed at runtime. Keep in mind that while these hashcodes, loading order and format are all set in stone, the files themselves (as well as their names and contents) are not, other than their general structure. The files are listed in chronological order since game startup, unless otherwise indicated. Game boot Hidden loading bar and nothing else gets rendered. One bootup file for all languages, even if there are multiple ELFs they decided to use the English version. After this, we also need to load the language-dependent pickups file; which includes the main font and the memcard dialog. Because every language has its own font, with a different set of Unicode glyphs, we need it now. At this time we also start loading the text file, at least the section zero for the memcard text. Keep in mind that this file is pretty big, and only the basic header and the needed sections are actually relocated on RAM. Everything else persists on disc. Black until now. After all these files are synchronously loaded HT_Script_Bootup_MainScript is retrieved and starts showing. This script has a special HudScript_Button scripted event of type HT_HudScriptButton_Memcard_StartupCheck that will wait for the memcard to be ready before proceeding. The button sets the next chained script to HT_Script_Bootup_LegalScreen, that will become active when reaching the HudScript_Jump event at the end of the timeline. So the only hardcoded part is that this main script is loaded, most of the other events are configurable. The initial legal screen script (HT_Script_Bootup_LegalScreen) should start after the HudScript jump, the game waits for the legal script to start before proceeding any further and starting the hidden loading screen, all the previous synchronous files should be loaded at this point. One-off static data initialisation All these spreadsheets and resources are asynchronously loaded, their data imported and their EDB files unloaded, all this is only done once while the legal screen is showing. It won't fade out until all these files are processed. Front-end These are normal, technically playable Mummy maps, at least at surface level. Due to the way each of these files are loaded, they receive a somewhat special treatment from the game. Each language has its own clone of the main menu map, Eurocom calls it the FrontEnd. Depending on the current language these and their PickUps counterparts are conditionally loaded, falling back to the English version if the format isn't supported. The front end level can also be loaded from the pause menu. Each of these files contain the Uruk map itself, a simple script that works as a cutscene and has the choreographed camera movement loop, another HudScript that lays out the main menu buttons and submenus, which is also extensively configurable. With the limitation of using special HT_HudScriptButton_ types for hardcoded behavior, like triggering the memcard dialogs, loading or creating a new game, launching the video player or for the inner working of the dynamic settings and their labels. Incidentally, the other major HudScript is the pause menu. Counter intuitively, neither the HUD itself nor the item rotator nor the Book of Sphinx use HudScripts, choosing to use hardcoded entities and scripts whose behavior is directly controlled by the game's code, instead of being laid out in EuroLand via a simple event timeline. : EngineX script → not to be confused with a map gamescript (which is a piece of code used in a map trigger instance), scripts are Adobe Flash-like scenes; visual timelines used to lay out timed events in 2D or 3D. They are mainly used for cutscenes, as well as working as the final container for character animations when configuring their AI, attack patterns, collisions, weak points and behavior. They are extremely flexible. : They can contain animated characters, particle effects, loop points, animated cameras, timeline-animated entity instances and much more. For example: a breakable vase might be made out of a few static entities (a normal version plus a version broken into several pieces) and particle effects, the script is where all those ingredients are turned into the final object; maybe the first frame shows the unbroken vase, and the timeline is tagged to be frozen there with a special event tag that will play the rest whenever a hit happens. The other frames will animate the instances of the flying pieces and the object slowly fading away frame-per-frame until reaching a stop point. : HudScript → a special type of EngineX script with clickable buttons and conditional jump points that can be configured directly via EuroLand using a few specific event primitives. It can call and contain animated movement, as well as other sub-scripts; for example, reusable button templates. Again, it's made out of normal 2D and 2.5D entities. For example: the game over screen and its swirling background. : Hardcoded screen elements → special game windows that are overlaid over the in-game camera and can use fixed entities, texture regions, text and scripts and affect them programmatically. The assets are usually referenced by hashcode, so they can be skinned, but we can't add or alter buttons without changing the game's source code. For example: the health bar with the Gold Ankhs or the Bronze Scarab counter. Level initialisation Each time we switch to a playable level, several things happen. HT_SubFile_File01 https://gist.github.com/Swyter/dc660d27204a14323256e2ca8dc42fe2 A map can only contain at most 128 submaps.Category:Game development